KarpathyのLLM Wiki勉強会

イメージ図

https://gyazo.com/6f567b7bf594538a9f1724f9d97bbf01

サイボウズラボ勉強会 2026-05-22

KarpathyのLLM Wikiについて話す

今回GPT5.iconアイコンのついているツリーはChatGPT 5.5 Pro、KarpathyのLLM Wiki.icon/Karwi.iconがついているアイコンはKarpathyのLLM Wikiが生成しています

「KarpathyのLLM Wiki.icon」は、何らかアイコンがないと出力したAIを明示しにくいので適当に生成させたもの

KarpathyのLLM Wiki

gpt5.iconKarpathy = Andrej Karpathy（アンドレイ・カルパシー）。現代AI界隈ではかなり影響力のある研究者・教育者です。

2015年のOpenAI立ち上げ時のメンバー。

2017年にTeslaへ移り、Autopilotのコンピュータビジョン系AIを率いました。

Stanfordの有名講義 CS231n: Convolutional Neural Networks for Visual Recognition の中心人物でもあり、YouTubeやGitHubでもニューラルネット、LLM、nanoGPTなどをかなりわかりやすく教える人として知られています。

2024年にEureka Labsを創業: 現在はAI教育プラットフォーム Eureka Labs を作っていて、LLM101nなどの教育コンテンツを展開しています。

「vibe coding」という言葉を広めた人でもある

LLM Wiki文脈でのKarpathyは、ざっくり言うと「チャットを一過性の会話で終わらせず、LLMが読み書きできるMarkdown Wikiとして知識を蓄積する」方向を提案・実践している人です。

nishio.iconこの資料を作った後5/20にKarpathyがAnthropicに入社したニュースが流れてきたw

ここで解説する「KarpathyのLLM Wiki」の仕組みは、より一層Claudeとセットで動くようにチューニングされてClaudeの標準機能としてリリースされるかもな

2026-04-03 に KarpathyがX.comに投稿した「LLM Knowledge Bases」と題する投稿が大バズり

2026-04-05にフォローアップの投稿でブートストラップのGistが共有された、このGistが"LLM Wiki"というタイトルなのでこの名前で呼んでいる

理論の新しさよりも、実装負荷の低さ

マイナスのデザイン

気をつけないと、どんどんと色々な要素を付け加えてゴテゴテしたシステムになってしまう

ボタンが大量についたテレビのリモコン

多くのニーズに対してそんな複雑なシステムは必要なくGist1枚でOKであることを示した

RAGと言う言葉がバズり出した2023年前半には確かにコンテキスト長が4Kしかなかった(GPT-3.5)ので「色々工夫してなんとか実現するしかない状況」だった。2026年現在は256倍の1Mになってる(Claude Opus 4.7)

この件については以前まとめた: ロングコンテキスト時代のベクトル検索型RAGの卒業

歴史的に見れば「リソースが限られている状態で目的を達成するために色々試行錯誤して複雑なノウハウの塊ができるが、リソースが潤沢になったらそれらはほとんど必要なくなり潤沢なリソースでシンプルに処理すれば良い」という頻出パターン

富豪的プログラミング

もちろん周縁部でこういう工夫の必要なユースケースは残るが「多くのニーズに対して」はシンプルな方法でOK

以前概念マップ勉強会で話したGraphRAGの頂点やエッジがとてもリッチになったものとも解釈できる(=Markdownのページとページ間のリンクになった)

GraphRAGに関しては「三つ組」のレベルまで簡素化することが性能を落とすという議論もあり、「グラフ」ってとこまで抽象化しないでリッチな文脈を保ってた方がいいんじゃないのという方向性があった

Karwi.iconWu et al., "Memory in the LLM Era" (PVLDB 2026, arXiv:2604.01707) — 10手法の統一比較で「Mem0g(graph版) より Mem0(非graph版) が上回る場面が多い、情報損失が少ないから」と報告

これを面白いと思っていろいろ試してみている

リリースから1ヶ月、2026-05-07時点で20個以上作ってるのでいろいろ比較して語れそう

(内容を語れないものも多い / ちょっと試してみただけであまり発展していないものもある)

Wikiについて

「Wiki」という言葉にもつイメージが人によって割と異なっていると思う

A: 他人が作ったものを読むイメージ

このイメージの人が一番多いと思う、具体例はWikipedia

コンテンツ文中の単語から他のページへのリンクがある情報表現形態

GPT5.iconWikipedia によって広まった後発のイメージです。Wikipedia はWiki技術の成功例ですが、「Wikiの本来」ではなく、「Wikiを百科事典制作に適用した巨大な派生形」と見る方がよい。

B: チームでの情報共有のために書く場所のイメージ

これはAと違って「自分が書くこと」がイメージに含まれている

だがその書き方はチーム/組織のカルチャーによってまちまち

B-1: Aのスタイルの「リンクの豊富なドキュメントによる知識のネットワーク」を共同生産してるケース

gpt5.icon(本来の)WikiWikiWeb はソフトウェア設計パターンをめぐるプログラマ共同体の知識形成の場だったので、B-1に近い。

B-2: 「単なる共有のドキュメント置き場」になってるケース

"リンクの豊富なドキュメント"でないただのレポートがフォルダで階層管理されてたりするやつ

暗黙の前提として「他のチームメンバーに共有するため」という目的が仮定されがち

C: 個人での情報整理のために作るもののイメージ

本来のWikiから「未完成の知識をページとリンクで育てる」の要素が残り「著者と読者を分けない共同編集の場」の要素が消えたもの

Bと違って「他人に共有するため」が前提ではない

C-1: 非公開で他人に見せないケース

こちらがメイン

C-2: 「読んでもよいが、読む必要はない」というノリで公開されているケース

Cのごく一部が著者のノリで公開されており、そういうものだけが読者の観測範囲に入る

このCosense「西尾泰和の外部脳」は基本はC-2のスタンスで公開されている場で、たまにB的に今回のように「他人に共有するため」の講義資料を置いている

human.icon社員みんなでウィキをメンテする

nishio.iconこれは根本的な勘違いで、人間はWikiをメンテしない

Wikiの3パターンの議論で「B: チームでの情報共有のために書く場所」のイメージを引きずると「人間が手で書く」と思いがちだが、本資料の文脈での「メンテ」はLLMの仕事

人間がやるのは ingest 指示・対話・file back の判断

human.iconC1で始めたが、いいところだけをBで公開するのもアリかなと思い始めた

nishio.icon選択的公開がやりやすい形にできるといいね

将来的には自分のものも部分公開したいが「部分的に公開、他は非公開、それを適切にアップデート」を運用するのが面倒で、今は「自分が見るだけ」に倒している

今回の文脈「KarpathyのLLM Wiki」では、メインフォーカスは「C-1: 非公開で他人に見せない」だ

データのフォーマットが「コンテンツ文中の単語から他のページへのリンクがある情報表現形態」なのでWikiと呼ばれているが、個人的には投稿1の"LLM Knowledge Base"の方が適切な表現で、さらに言えばほとんどの場合で"Personal LLM Knowledge Base"だと思う

Personalなので当然「実物をありのままに」他人に共有することが困難で、公開しやすいものだけ公開され、公開されたものだけを見る人は公開によるバイアスが乗ったものしか観測できない

だからみんな自分で色々なデータで試してみるべきだと思う

作ってみよう

個人的なデータが入ってるものは見せられないし、作るプロセスを紹介した方がいいので新しく作る

テーマは適当に決める、ちょうどgpt-realtime-2が周囲で話題になってたのでこれにしてみよう

適当にフォルダを作って、llm-wiki.md を置く。ついでにrawフォルダも作っておく

https://gyazo.com/b39242d40b510719b20d68f2ec87dfa8

なにかrawに入れよう

個人的なWikiなら個人的なデータを入れたりする

今回はそれだとデモできないのでGPT 5.5 Proに解説させてみる

https://gyazo.com/37cceb611f68ecee8f7e59d755b361d9

Markdownでコピーしてrawに置く

https://gyazo.com/cb727acccee6e716b5ff34d91dcc2e0a

Claude Codeに整理してという

https://gyazo.com/ced2d804a048be2995fd31907ef5beba

human.iconQ: @llm-wiki.mdって何？

nishio.iconVS Codeのclaude code拡張の@記法

@ でファイル一覧、選んだファイルへのポインタが入る

明示的にatで指定したファイルと、暗黙的(VS Codeで開いてるファイル)の両方がコンテキストに入る

human.icon何か専用のスキルを入れている？

nishio.icon専用のスキルは入れていない

Gistにスキル相当のことが書いてあるのでそれを見てやってもらっている

なんからのコーディングエージェントがあれば大丈夫、Skillsとかへの入れ方を知らない初心者でも動く

human.iconコーディングエージェント何を使っている？

nishio.iconClaude Max Pro でやることが多いけどClaude Teams Standard でも動くはず

Claude CodeとCodexが同じWikiを読み書きしながら動いている

https://gyazo.com/ce04191d4a624344eb0eddd74f7f498f

この提案も面白いけど、まずは一旦Wiki整備に集中することにする

https://gyazo.com/62b570083f4619f5a168cbf1ad3c4802

今回の目的だと「サーベイ」なので僕の手元にあるデータは少なくネット上にあるデータが多いからWebSearchはやってもらった方がいいね

https://gyazo.com/94ab497cdcc3be09adc97148d5657679

プロトタイプ案も作ってくれるんだ、親切〜

しばらく待つ

https://gyazo.com/5c152b42ed8a2febc560c36b2f436fb3

CLAUDE.md

https://gyazo.com/ed3e983b664a9b20fc08ed0765ea6276

データ追加の例

GPT Proで追加でサーベイした想定

https://gyazo.com/5efb57cc21016612c01f7d377920e31c

またrawにおいてingestを指示する

https://gyazo.com/a07b6747ad7bbf88565e2dce72d362ac

https://gyazo.com/c2603195b66473a92d81bd45aba2b304

KarpathyのLLM Wiki.icon取り込みで見えた論点

thinker-responder(後述) が「速い音声 + 深い思考」の事実上のベスト構成として複数事例で示唆されており、wiki の concept として独立ページに昇格させた

評価軸が「自然さ」より通話成功率・割り込み回復率・タスク完了率にシフトしている（Genspark / Bluejay / Zillow）

Sokuji の整理(後述)は wiki の comparisons ページに足りていなかった「実装視点」を補ってくれる

thinker-responder

https://gyazo.com/d2ff02eb82999a94d72b831d7f23f289

質問回答できる

https://gyazo.com/1016c38f7cba7269e587d40b0c459161

新しいアイデアを思いついた想定

「スマートスピーカーのようなウェイクワード呼びかけでセッションが始まって音声でやりとりできるプロトタイプを作りたかったらどうしたらいいかな？」

https://gyazo.com/60a0f7dd706986c37e79d7b37b97d723

詳しいことを聞いてくる

https://gyazo.com/518dbf3d18d4d1ed1b2d9d805ff38b62https://gyazo.com/1b943befaf80aace991cb0651383a35ehttps://gyazo.com/c64e14e5761b675d11b4c5775aadef01

設計メモのページができた

https://gyazo.com/0ed257613074a27fcd8282ede8e8bdaf

見てみる

https://gyazo.com/069983bf145b796268cc42cbc1aee9d1

なるほど〜

同一内容をGPT Proに投げたもの

https://chatgpt.com/s/t_6a014f55d58c8191aa26086faaee578a

こちらはClaude Codeが途中で挟んできたような「今回は実装したいのか設計ドキュメントを作りたいのか」という質問が挟まらずに大体同程度の時間(7分)走って、疑似コードや設定ファイルが出力されている

これもingestしておけばいい

https://gyazo.com/f69d30a0d81d50257d587acef8b244cdhttps://gyazo.com/fb3920c65891eacd221c0b4775584800

すぐにでもプロトタイプ作成に着手できそうだけど、今日は他にすることがあるから一旦ここで保留

保留している間に関連した記事を見かけたりしたらingestしたらいいし、質問やアイデアが生まれたらClaude Codeに話しかければいい

こういうイメージ

https://gyazo.com/68facfcbbdee7330773daa45bfaf20e2

1: まずスタートがある(今回は「gpt-realtime-2ってのが出たらしいな」)

2: AIにサーベイさせたり考察させたりして「探索」が行われ、マップが広がっていく

どういうことが可能なのか、どういう部品が必要なのか、の地図ができる

たとえば、部品「ローカルでのウェイクワードエンジン」を実現するには2つ選択肢があり、それぞれどういうメリットがあるか

3: いつかのタイミングでもっと具体的なゴール「こういうものが作りたい」が生まれてから

4: 今までの探索範囲の中からそれに関係するものを集めて形にする

もう少し補足

https://gyazo.com/32264e3c37cb725ba214740678f764ff

A: LLM以前、Google以降の時代

何か知りたいことSがあったらそれで検索してヒットしたものを読む

複数のドキュメントで共通して書いていることは重要なことだな〜

前提知識なしでわかるように書かれてないブログ記事があったりする

初見の時には意味がわからないが、他の記事を読んだあとで意味がわかるようになったりする

このプロセスで個人の中に知識のネットワークが育っていく

B: Deep Research以降、または検索エンジン以前の時代

何か知りたいことSがあったらそれでDeep Researchすると整理されたドキュメントが出てくる

(検索エンジン以前の時代は何か知りたいことSがあったら図書館や書店に行ってSに関する「整理されたドキュメント」としての書籍を入手していたので獲得コストを度外視したら似た形)

これを読んで個人の中に知識のネットワークを作ることができるか？

1回さらっと読んだだけでは知識のネットワークが育たない

結局、何度もいろいろなものを読んで、重要なものが繰り返し出現することで定着していくのだと思う

LLM Wikiは、この「知識のネットワーク」を人間の外側で作っている

特にハブ的になっているページや頻繁に更新されるページを繰り返し読むことことは効率良い知識獲得につながりそう

「人間の中」ではなく「外」にあるので、それをAIが読んで回答することができる

human.icon人間の中に知識のネットワークができにくくなるのは、まあ大した問題にならない？

nishio.icon確かに何かを成し遂げる上で、AIが全部の作業をするのであれば、究極人間の中に知識のネットワークが構築されなくても目的が達成されることはあり得る。

その「目的」が目的であり、「人間の中に知識のネットワークができること」は従来型の目的達成の手段にすぎない

ただし人間の「目的」や「期待」は AI に分からないので、人間が言語化して伝える必要がある。

人間が目的を言語化して伝えることができていない、そこでAIと対話していくことが目的の言語化の支援になっている

KarpathyのLLM Wikiの3つのアクションの定義

Ingest

Ingest. You drop a new source into the raw collection and tell the LLM to process it. An example flow: the LLM reads the source, discusses key takeaways with you, writes a summary page in the wiki, updates the index, updates relevant entity and concept pages across the wiki, and appends an entry to the log. A single source might touch 10-15 wiki pages. Personally I prefer to ingest sources one at a time and stay involved — I read the summaries, check the updates, and guide the LLM on what to emphasize. But you could also batch-ingest many sources at once with less supervision. It's up to you to develop the workflow that fits your style and document it in the schema for future sessions.

取り込み。新しいソースを「raw collection」に追加し、LLMに処理を指示します。処理の流れの一例：LLMがソースを読み込み、重要なポイントをユーザーと議論し、Wikiに要約ページを作成し、インデックスを更新し、Wiki内の関連するエンティティや概念のページを更新し、ログにエントリを追加します。1つのソースで、10～15のWikiページに影響を与えることもあります。個人的には、ソースを1つずつ取り込み、その過程に関与し続けることを好みます。つまり、要約を読み、更新内容を確認し、LLMに対して何を強調すべきかを指示するのです。しかし、監督を最小限に抑えて、多くのソースを一度にバッチ処理することも可能です。自分のスタイルに合ったワークフローを構築し、将来のセッションのためにスキーマに文書化するのは、あなた次第です。

KarpathyのLLM Wiki.icon1ソースが10〜15ページに触れるという量的記述が重要。単発の要約ではなく既存ネットワークへの編み込み作業であることを示唆している。

1. raw/の新ファイルを読む

2. 既存wikiページと照合

3. 関連ページを更新 or 新規作成

4. index.mdを更新

5. log.mdに記録

nishio.icon僕はオリジナルのものに加えてこう追記してある

If given file is like a.txt rename properly.

Query

Query. You ask questions against the wiki. The LLM searches for relevant pages, reads them, and synthesizes an answer with citations. Answers can take different forms depending on the question — a markdown page, a comparison table, a slide deck (Marp), a chart (matplotlib), a canvas. The important insight: good answers can be filed back into the wiki as new pages. A comparison you asked for, an analysis, a connection you discovered — these are valuable and shouldn't disappear into chat history. This way your explorations compound in the knowledge base just like ingested sources do.

クエリ。ウィキに対して質問を投げかけます。LLMは関連するページを検索し、それらを読み込み、出典を明記した回答を生成します。回答は質問の内容に応じて、マークダウンページ、比較表、スライド資料（Marp）、グラフ（matplotlib）、キャンバスなど、さまざまな形式で出力されます。重要な点は、優れた回答は新しいページとしてウィキに保存できるということです。あなたが求めた比較、分析、発見した関連性——これらは貴重なものであり、チャットの履歴の中に埋もれてしまうべきではありません。このようにして、取り込まれた情報源と同様に、あなたの探求の成果もナレッジベースに蓄積されていきます。

KarpathyのLLM Wiki.iconKarpathyの記述では Query の中に filing back が埋め込まれている。回答が「チャット履歴に埋もれて消える」のを防ぐ仕掛け。

回答が次の回答の文脈になる → 複利効果の中核

同じ質問を繰り返さなくて済む

探索 = wiki強化という正のフィードバックループ

nishio.icon

質問をして、出てきた回答を見て人間が「それをfile backしといて」というケースだけでなく

「これはfile backしときましょうか？」とAIの側が言ってくるケース

ひと段落ついた時に僕が「このログにfile backすべき知見はある？」と聞くケース

特に実装的なやり取りをした後にやる

「3つあります、1は新規ページの追加で〜、2と3は既存ページの更新です」みたいなことをAIが言う

nishio.icon

これは人間のアナロジーだと質問は言語化を促すだ

目的が明確になってからその目的達成のための生成をしているとも言える

Lint. Periodically, ask the LLM to health-check the wiki. Look for: contradictions between pages, stale claims that newer sources have superseded, orphan pages with no inbound links, important concepts mentioned but lacking their own page, missing cross-references, data gaps that could be filled with a web search. The LLM is good at suggesting new questions to investigate and new sources to look for. This keeps the wiki healthy as it grows.

Lint: ：定期的にLLMにウィキの健全性チェックを依頼しましょう。具体的には、ページ間の矛盾、新しい情報源によって古くなった主張、外部リンクのない孤立ページ、言及されているにもかかわらず専用ページがない重要な概念、欠落している相互参照、ウェブ検索で補えるデータの欠落などを確認します。LLMは、調査すべき新たな質問や探すべき新しい情報源を提案するのが得意です。これにより、ウィキが成長するにつれて健全な状態を維持することができます。

KarpathyのLLM Wiki.icon

機械的検出=孤立ページ、壊れたリンク、未登録

意味的検出=矛盾、stale claim、概念不足の判断、新質問の提案

The LLM is good at suggesting new questions to investigate and new sources to look for.

→ Lintは単なる健全性チェックではなく、wikiの成長方向の提案までやる。

nishio.iconAIが自動的に呼び出してることもある

Wiki横断で「しばらくLintをやってないものを発見する仕組み」を作って、寝る前に実行するつもりだったが、予想よりも自動的に整えられていることが多い

human.iconfile backは必須？

nishio.icon必須かというと必須ではないが、AI要約をするときに個人的コンテキストを入れて要約した方が入れないで要約するより個人にとって有用なものが得られるのと同じ意味で「やった方がいい」と思う

human.icon自分のために使うなら、読んだ結果のフィードバックをしない理由はない

nishio.iconそこは同意なのだけど「フィードバック(感想)」と「File back(操作)」の話が混ざって混乱が起きそう

「フィードバック」は「AIの出力に対する感想」のこと

「File back」(ログから知見を抽出して恒久化する操作) とは別物

フィードバックしている

僕はAIが面白い出力を返してきたときには「面白いね」と言ってるし、イマイチだなと思ったら「イマイチだな」って言ってる

イマイチだなと言ってから事後的に「どうイマイチか」が言語化される

AIが代案を出してきたりして「お、それの方がいいね」となったりする

こういう情報こそ言語化された情報ソースにない重要な情報なので積極的に入れる必要がある

human.iconグループウェアのコメントを片っ端から突っ込んだらいい感じになるか?

nishio.iconいい感じにならないと思う

目的が定義されてないと評価できない、「要約」以上のものにならない

フロー情報を全部突っ込むスタイルでやると早く限界に到達する

大前提としてindex.mdに全ページのサマリーを置くので、雑多なものが多すぎるとキャパが圧迫される

CLAUDE.mdに雑な物が大量に突っ込まれている状態と同型で良くない

この問題を解決するためにAgent Skillsが生まれてきた歴史を無視している

対策案

目的を絞る (例「XXXを改善するための議論だけ入れる」)

グループウェアのログに対する横断検索をエージェント自体にさせて、目的に関連したものを集約する

human.iconデータを一方向で取るのではなく、グループウェアとAIで合体したシステムにして、流通のサイクルを作りたい(=これを「フィードバック」と呼ぶ)

nishio.icon同感だが、長期的な目標。最初の一歩は人間側の利用から

共通する運用方針: 「事前にやろうとしない」

Karwi.iconIngest/Query/Lintを実際に回す中で気づくのは、多くの運用判断が「事前計画/事前検証/事前判別を放棄する」で揃うこと。

table:_

局面「事前にやる」発想実運用

ingest検証更新10〜15ページを毎回チェックしない。間違いに気づいたら一括修正

Wiki配分どのWikiに入れるか最初に決める迷ったら両方。rawがimmutable

凍結判別短命/長命を最初に見分ける思いつかなくなったら自然停止

kabuwake 実装系/研究系を最初から別Wiki 育ってから「目的の言語化」で分ける

成立条件は事後修正コストの低さ = LLMによるcost inversionの帰結。

事前計画/検証/判別のコストは下がっていないので、放棄が合理的になる。

猫Wikiの「rawに入れさえすれば後で構造化される」も同じ原理。

nishio.icon例えば

ingestで10〜15ページが更新されるが、それを毎回チェックはしない

間違いに気付いたタイミングで指摘すれば、AIが10〜15ページをガリガリ修正してくれる

どのwikiに入れるか最初に決める必要はない、迷ったら両方に入れたらいい

それぞれのWikiで目的や文脈が異なることによって、異なる側面が切り出されて発展していく

どっちのWikiにとっても有益なので両方したらいい

体験談

家計Wiki: 「必要な情報」が後から分かる

猫Wiki: 高速膨大な情報インプットから心を守る

dd2030-wikiでの具体例: 経緯を思い出す

LLM Wiki自体のLLM Wiki: 研究目的のWikiとプロジェクト目的のWikiの区別

中にコードリポジトリを持つパターン

家計Wiki

LLM Wiki以前から確定申告を手伝わせるつもりでClaude Codeに色々な詳細データを与えていた

ソフトウェアプロジェクトみたいにフォルダを作ってCLAUDE.mdとデータを置いて処理

確定申告とは違うけど友達がGPTの指示の通りに株取引したら自分より儲けるって言ってて興味を持ったので自分の資産を分析させたかった

これをLLM Wiki化した。初期の3〜4個のうちの一つ

「必要な情報が後からわかる」

「他に必要なデータある？」とLLM Wikiに聞くことで何が必要なデータかわかる

人間は事前に「適切な判断に必要なコンテキスト情報」を特定して全部渡すことが難しい

具体例「家族構成は？年齢は？」

確かにそれを把握しないで将来の計画ができるわけがないね

具体例「保険金の支払いがあるが、この保険契約の内容は？」

即答できない

保険証書を出してきて概要を読ませたら解約返戻金テーブルも見せてと言われた、解約した方が良い可能性を検討されてる！

具体例「年金ねっとの情報を見て」

言われるまで思いつかなかったが「株式と債券のバランス」という文脈において年金は強い債券的性質を持っている

年金額が利息になるような債券とみなせる

もらえるのかどうかは疑問だけどもw

GPT5.icon

年金をまったくもらえない確率はかなり低い。私の見立てでは 1〜5%未満。

一方で、今の高齢者や現在の制度説明から期待する水準より、実質的・相対的に少なく感じる確率は高い。70〜90%程度。

財政検証の低成長側では、国民年金の積立金が2059年度に尽き、完全な賦課方式へ移行するケースも示されています。その場合でも、保険料と国庫負担で賄える給付水準は所得代替率37〜33%程度、機械的調整を続けた場合は2059年度時点で50.1%、さらに調整した場合45.3%という記述になっています。

こういう情報を与えて参考にさせることができる

猫Wiki

「高速膨大な情報インプットから心を守る」

2026-04-27に緊急入院して毎日血液検査をしてる猫の情報を整理

多い時には1日2〜3枚の血液検査結果のデータと、医師の話、GPT Proによる各種の概念の解説

まず初日に検査データをGPT Proに与えて解説させたが、未知概念が急激に増えるので人力での整理の速度が追いつかない

追いつかないまま翌日にはまた新しい検査結果がくる

「知識は恐怖の解毒剤」

状況を理解できないのは強いストレス

2026-04-30

毎日20個も数字が書かれた検査データの紙をもらう上に今日は元々の病院の1枚に加えて大学病院でも2枚もらった(し多分明日以降2枚ずつ来る)

先生の解説やデータの読み方は人間(僕)が手動で整理してたんだけど、妻が状況を把握して安心したり、先生の話を聞いて理解しやすいようにまとめることまで射程に入れるともうキャパオーバーなので、ここでLLM Wikiを使えばいいのではないかという気持ちになっている

このとき緊急入院から4日目

14個目のLLM Wikiを作った

KarpathyのLLM Wikiによるタイムラインまとめからのnishio.iconの要約

2026-04-27(月) 朝9時 — かかりつけ病院

朝にかけてたくさん嘔吐

来院 → 輸液を投与

2026-04-27(月) 17時 — 容態悪化、紹介

嘔吐が止まらない(1時間に1回ペース) / よだれが止まらない

別の病院に移送

低カリウム血症、急性腎不全の可能性

2026-04-28(火) 血液検査(2回目)— 「何らかの炎症」の判断

急性腎不全というほどではないがなんらか他の臓器に炎症がありそう

2026-04-28(火) 画像検査— 膵炎判明

膵臓の腫れ → 急性膵炎

2026-04-29(水) 13時

抗炎症薬が膵炎に効かない

別途ビリルビン値が上昇、肝臓・胆管の問題の可能性

16時なら大学病院が受け入れ可能とのこと

2026-04-29(水) 大学病院 — 入院後のエコー所見

心肥大が見られる

腹腔内の脂肪の炎症(膵周囲脂肪の炎症と推定)— 中等症以上の膵炎で見られる所見

胸水(胸腔内に液体貯留)

~2026-05-02

腎臓は安定

fPL上限越え: 膵炎を強く支持

改善: SAA 136.9 → 68.7、WBC 217 → 209.9 → 全身炎症は下がってきている

悪化(肝胆道系): 総ビリルビン 2.5 → 5.3、ALP 157 → 334(いずれも大きく悪化)

血糖と貧血がで始める

医師所見

肝臓に肥満細胞腫(MCT)がありそう

胆管が太くなっている

ステロイドの点滴で肥満細胞腫と炎症を抑える

~2026-05-04

「全身炎症・腎臓・電解質はかなり改善してきたが、胆汁うっ滞/黄疸だけがまだ進んでいる」という結果

治療が効いている部分(SAA・K・腎数値・血糖・Alb・Hct・嘔吐)と、まだ効いていない/遅れて悪化している部分(T-Bil・ALP・fPL高値)が分かれる

2026-05-05

大幅改善(肝胆道系) :

総ビリルビン 7.6 → 1.5(劇的に低下) — 黄疸の山を越え始めた

ALP 450 → 148(同じく大幅低下)→ 完全な胆管閉塞が進行し続けるシナリオは大きく弱まった

貧血は進行している

自力での摂食がみられる

~2026-05-07

fPL(膵炎の指標)が計測範囲内に戻り始める

2026-05-10

退院

感想

序盤(急性腎不全~急性膵炎)がやばい

猫が明日にも死ぬかもしれない状況で、何が起きてるのかを理解するために未知の用語が数十個出現する

時間と精神の余裕があるならGPT Proに聞けば説明はしてくれるが、情報量の多さを精神が受け止めきれない

4日の血液検査の結果を1日分ずつGPT Proが解説した、これを個別に人間が読むのではなくLLM Wikiが読んで「どのようなことが起きているか、それを示しているのはこの値で、時系列ではこう変化している」のように再構成して示してくれる。人間にとっての飲み込みやすさが違う。

(ログ取りに気を回す余裕がなくてgit管理してなかったから初期に自分が見ていたものを復元できない)

https://gyazo.com/beab364975a5e740d79382d21c7b9923

長期的視点

ChatGPT 5.5 Proのコンテキスト長さがいくら長くても、初期に書いた情報を覚え続けてくれるか信用できない

Claude Codeみたいにコンテキストが埋まって自動でcompactionがかかって、昔のことはぼんやりとしか覚えてない状態になるのではという不安感がある

それに対してこちらはrawファイルは一切いじられることなく手元のファイルシステムにあるので「何も消えない」という安心感がある

GitHubにpushするなりDropboxの中に置くなり任意のバックアップ方法でバックアップすればいい

特に異なる日にちょっとずつ足していったデータが時系列で整理されてるのが振り返るのにとても良い

https://gyazo.com/ee066e5b8a1fc7136c68b232bde4991f

fPLとは何をはかってるのか、どういう病気を見るためのものなのか、どう値が変化したかetc.

dd2030-wikiでの具体例: 経緯を思い出す

プロジェクトの過去の経緯をみんな忘れている状態で、AIを過去ログにアクセス可能にしてAgentic Retrievalさせる

出来事

昨年11月ごろに「新規参加者向けの解説ページが必要では」という話題になる

2025-11-22— NISHIO さんが Slack#コミュニティ運営で「GPT-5.1 に新規参加者向け解説を作らせた」と投稿

その後Aさんがこの内容をWebページに追加するPRを作成、Bさんがマージ

2025-12-02— C さんが deno lume への大規模リニューアルでパス修正

2026年5月に「このページってなんだっけ？」「最新の情報に追従してない」と話題になった

僕もBさんもCさんも「なんだっけ？」となった

SlackログとGitHubの両方を読めるLLM Wikiに質問したら上記のような経緯ですよと教えてくれた

考察

こういう「目立った名前のついているプロジェクト」の隙間のタスクが複数人の手によってちょっとずつ進んだようなケースでは、議事録に全体像が残らないので半年後に由来がわからなくなりがち

僕はGitHubを軽く調査して「12/1ぐらいにCさんがやったと思う」と思ったのだが結果的にそれは間違いだった

これは「すべてのデータをインデクシングする必要はない、AI Agentにrawデータを検索する手段があればいい」の実例

nishio.iconQ: これをどうやって突き止めたのかのプロセスの解説が欲しい

KarpathyのLLM Wiki.icon

2つのソースがある:

/tmp/oss_weekly_reporter/data/ — Slack/GitHubの週次アーカイブ（要約あり）

GitHubリポジトリ本体 — コミット履歴の真実

まずアーカイブ側で議論の文脈を、後でリポジトリ側でコミット事実を確認する2段構えにした。

議論の発生時期を絞る

「12/1ぐらい」を信じすぎず、前後（11月後半〜12月前半）の週をまとめてgrep

→ ヒットしたのは 11月19-26週。これで「12/1」の記憶は1〜2週ずれていることが判明。

ヒットしたファイル github_report-website.md を文脈付きで読むと、Issue #180 が見つかった:

起票者: Bさん（Cさんではない）

起票日: 2025-11-22

内容: 「NISHIOさんがGPT-5.1で生成した文章をそのままサイトに載せるのはどうか」

この時点で「CさんがAI生成した」という仮説は崩れた。

コミット履歴で裏取り

議論だけでは「実際に誰がページを作ったか」は不明。リポジトリをcloneして git log:

→初出はBさん、Cさんは後の構造リニューアル時の運搬役と確定

内容の同一性確認

初出コミットの中身が「NISHIOさんがGPT-5.1で生成した文章」と一致するかを git show d686234 -- markdown/newcomer.md で目視確認

LLM Wiki自体のLLM Wiki

LLW Wikiを知ったとき、まずGrokでKarpathyの投稿に対する反応をかき集めてLLMにingestさせた

その後LLM Wiki自体の体験談や関連しそうな論文サーベイなどをなんでも突っ込んでいった

だいぶ大きくなってきた中で、別のWikiに「株分け」したくなった

研究(サーベイ)目的のWikiとプロジェクト目的のWikiの区別

体系化された知識ネットワーク自体が目的であるケース

整合性のある大きなネットワークが目的

ChatGPT Proなどでのサーベイからのingestが多い

人間が哲学的な質問をしてAIが回答してfile back

なんらかの目的(ソフトウェア開発etc)があるケース

知識ネットワークの拡大が主目的ではなく、例えば実装などが目的

その過程で経験したトラブルや試行錯誤などの知識を保存したい

作業から得られた具体的知識をfile back

前者はどんどん抽象的になっていく

抽象的な知識の方が広い範囲に応用しやすい(=違う知識と結合しやすい)のでWikiの中心的ページになっていく

後者は具体のレイヤーに接続する必要がある

https://gyazo.com/29c3e4fa3acb342d44a566345ce5eaad

from 根無し草の知識

https://gyazo.com/1b407815bfa704fcfa4154739f7ab42e

畑村洋太郎技術の創造と設計 p.207

1: サーベイのWikiから具体的なプロジェクトを明示して「関連しそうなページをコピーして」と言えばOK

2: 最初にやった時は(1)のやり方をしたが、のちに逆の方が良いのではと思った

Karwi.icon

(1) 最初のやり方 = page-source kabuwake（5/06 ケース, LLM-Wikiから注釈駆動Wiki開発プロジェクトへの株分け）

親wiki（サーベイ）内で「関連しそうな既存wikiページをコピー」

112ページ → 21ページを Tier 別に厳密選別

broken wikilink 51件発生

(2) 逆のやり方 = raw-source kabuwake（5/15 ケース, 別WikiからLLM-Wikiの資料の吸い取り）

「既存wikiページは1ページもコピーせず」、raw/ の原資料だけを新wikiに複製

新wikiは raw を自分の文脈でingest し直す

broken wikilink は構造上0件

Wiki AからWiki Bにコピーする場合に

Wiki Aに短い文章でWiki Bのことを伝える(1)よりも

自分のプロジェクトの目的などを詳細に知ってるWiki BがWiki Aのナビゲーションを使って自分に関係する資料を取ってくる(2)の方が良さそう

相互にお互いのWikiのことを知っているのでfile backする時に「あっちに書こうか？」という問いかけが発生することもある

複数のWiki間の連携は面白さを感じるが、まだ良い方法が固まってはいない

各フォルダにllm-wiki.mdがあるのを利用してClaude CodeにfindさせてWiki一覧は作ってある

(追記)AI自身がingest停止を判断したエピソード

nishio.iconLLM Wikiを知ったときにまずGrokでKarpathyの投稿に対する反応をかき集めてingestした

Gistの1000件超のコメントやX上のリプライ・リツイートが膨大

1週間後、2週間後にも追加で外部サーベイをingest

KarpathyのLLM Wiki.icon「あんまり新規の情報が増えないから外サーベイはもう要らない、あなた個人の実験からの知見の方がウェイトが大きい」

→ それ以降はAIの自己評価に従って外部サーベイのingestを停止している

(追記)「(2) raw-source kabuwake」の方が良い理由「会場メタファー」

Wiki AにWiki Bのことを短い文章で伝えるのは、人間がうまく言語化できないことが多い

すでに活動しているWiki Bの方が「自分に何が必要か」をよく理解している

Wiki BにWiki Aのナビゲーションを使わせて、自分に関連する資料を取りに行かせる方が良い

「うちの本棚を見て気になった本持っていきなよ」というスタイル

おすすめの本をこっちが勝手に決めて送りつけるんではなく

(追記) 株分け後の書き戻し

具体的なソフトウェア開発wikiで得た知見が汎用的に有用な場合、AI側から「研究wikiの方に書き戻しましょうか」と提案してくる

「やっといて」で書き戻される

複数wiki間の連携は面白さを感じているが、まだベストプラクティスは固まっていない

(追記)LLM Wiki = ペルソナという捉え方

勉強会会場での議論

human.iconLLM Wikiは『ファイルの集合』であって、能動性がないと捉えている。「もう一人のLLM Wikiが読む」のニュアンスがわからない

nishio.icon僕の中ではLLM Wikiの知識を持ったエージェントがそこにいる、というメタファー

human.icon「弁護士が六法全書を片手に抱えている」イメージ？

human.icon「スーファミにソフトのカートリッジが刺さっている」イメージ

ソフトのカートリッジが刺さったスーファミが家に何体もあり、しかも平行で立っていて、それぞれが違うことをしている

nishio.icon今の瞬間、デスクトップにVS Codeが11個開いていて、それぞれ違うプロジェクトの別のことを考えている

nishio.icon「クロードコード君1人」ではなく、wikiごとに別人という認識

情報を共有していない別プロセスとして走っているクロードコードは、別個体と認識している

広聴AI開発wikiでは4インスタンスを並列で立ち上げて並列実装していることもある

開始時点まで共通の知識を持っていた人格が4つに分身して作業をしている

コンテキストの中身は共有していない=記憶は共有していない

学んだことを日記(=wiki)に書いて終了する

明日のインスタンスは今日の4インスタンスの活動の記憶を持って開始する

中にコードリポジトリを持つパターン

いくつかのWikiで新規開発をしていた

dd2030-wikiでの「リポジトリをrawの中にcloneして分析させた」経験から、既存のソフトウェアの開発でも開発対象のソースコードをWikiの参照対象すればいいじゃないかと考える

https://gyazo.com/27423bbb1fd5b1d040d54bcb525b817a

仕組みの解説: https://nishio.github.io/kouchou-ai-developer-wiki/concepts/wiki-driven-workflow/

下記「Coding Agentの歴史の振り返り」のもっと簡潔なイメージ図

https://gyazo.com/6f567b7bf594538a9f1724f9d97bbf01

Coding Agentの歴史の振り返り

https://gyazo.com/78d55ef4a3fac2f662ef8079a5c94527

1: コンテキストサイズが小さく、短いコンテキストでの補完などしかできなかった時代

2021年6月: GitHub Copilot technical preview

2: コンテキストサイズが大きくなったので対話的に実行可能になったが、Needle in a Haystack性能が高くなくてコンテキストが増えると方向を見失って混乱し始める時代

2023年5月: Claude が 100K context window を発表

2023年6月: Lost in the Middle、迷子になるよね問題

3: コンテキストを使い切るレベルまで有用な性能を保ち続けられるようになった時代

コンテキストを使い切って急に作業中断されると困るのでコンテキストのコンパクションが行われるようになった

が、実感としてコンパクションすると過去の記憶がぼんやりして混乱しがち

2024年3月: Claude 3 "Long context and near-perfect recall"

Introducing the next generation of Claude \ Anthropic

2024年3月: Devin

Cognition は Devin を “first AI software engineer” として発表

「10ACUを超えると失敗しがちなのでそこまでいかないコンパクトなタスクをやらせるのがおすすめ」